本以為SM的案子就結束了，RJ打算讓其他人休完假後，再趕因為SM簡報造成已經有點落後的其他案子。大老闆Servo心想的是將這幾日得到的心得變成公司的資產，如何藉由其他六位已經有理論基礎的同仁，一起推廣成公司的基本功。Servo自我安慰：這個案子沒拿到，也許反而是好事，讓公司有機會改變聽命行事，低價搶單的代工模式。

大家意外的是簡報的隔週，SM公司 CIO 約Servo非正式聊一下。

“Servo，那次會議你談到 Unified Process 是否是 Jacobson 的 Objectory Process? 我請同仁深入了解，現在似乎沒有Unified Process這樣的說法” SM 的 CIO 其實在會場上已經看出大佬對 Servo 以及T軟很有興趣，當然不是因為Servo帥，而是他提出一套思維或是他宣稱的 Process，似乎是可以解決SM軟體開發要上線前總是突然發現有些問題，而且每次事後檢討，問題永遠都是用戶需求不明確呢！所以會議一結束，馬上召集主管會議，要求針對Servo 所說的 “Unified Process” 做深入研究。

“個人的確是受Jacobson Objectory Process影響很大，但是我堅持還要用 UML來輔助，所以我簡稱為Unified Process” CIO 是專家，Servo 清楚這樣的回答就夠了。

“我印象你有次跟我解說貴公司利用 UML Use Case 來做需求分析設計的工作，經常可以意外挖掘出需求背後的需求，而且這種一不小心就被忽略的隱藏需求，常讓專案實施宕延。我理解你說的UML 應該是指這個機制”。CIO 是聰明人，知道從供應商學東西，有時比找顧問上課實用許多。

“的確是，當時UML還沒有定案時，我覺得一些圖示對我們做物件導向程式開發實在太重要了，在我們公司這幾年就陸續推廣，多數同仁都以為其中的 Class Diagram 最有用。但是以我的角度來看，源頭卻是 Use Case。UML 幾個技術環環相扣，若以管理，專案成員，客戶等多個角度來看，都有其重要性。所以我反而不特別指名 Use Case”。

“你簡報的 Unified Process 是針對我們公司這個案子？” CIO試探性問一下。

“坦白講兩三週前，我是為了爭取案子出奇招，但是在準備簡報過程中，深深思考過去T軟遇到的困難，我已經在規劃要在半年內變成我們公司員工必備知識，我給自己的檢驗標準是未來一年，新接的案子必須有五成以上採用Unified Process。” Servo工程師出身，喜歡直來直往。

對於已經彼此信賴的夥伴不必隱晦。

“我口頭非正式的邀請貴公司加入我們這個案子，有兩個模式：當環球管理顧問公司的下包，這個我與環球管理顧問公司閒聊過，他們以前跟你合作過，很喜歡貴公司。或者你也可考慮獨當一面。”

“CIO你清楚當這種國際公司下包的軟體開發案的窘境，我寧可不接。現在我們承包小案子，利潤不高，但穩紮穩打，日子也過得去。”

“但是這個案子估計是需要近600人月的工作量，以一年專案時程來看，平均要有五十位同時作業。幾乎是現在貴公司的規模，你怎麼因應？”

“第一：傳統專案作法，先集合一群人，卻因各種角色工作量高低峰的差異，常會讓一堆人處在閒置的狀態，Unified Process 可緩解此問題，另外我正在推動師徒結對開發制，可解決人員調度問題”。幾年後，當Servo聽到 RJ與Gavin 聊 XP, Extreme Programming, 又覺得有點不平：為何沒人或文件記下是他先提出 Pair Programming的，儘管兩者立意差距頗大。

經過來回多次的拉鋸，T軟獨立承攬了SM該軟體開發案，雖然合約限制兩年內T軟不得承接SM競爭對手案子，但爭取到專案成員超時工作可額外報銷加班費。這一年是兩家公司的 UP元年。